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RLC layer below the PDCP layer, one RLC entity receives data packets from 
several radio bearers at the same time. 

[0040] Figure 5b illustrates a situation, in which a PDCP entity 
receives data packets through one radio bearer from two different 
applications, A and B. The data flows in the radio bearer are distinguished 
from each other on the basis of IP header fields before the header field 
compressor in the PDCP entity, after which the data flows are taken to be 
compressed. The compressor distinguishes the data flows from each other by 
defining them separate context identifiers, by means of which the 
decompressor of the receiver can again distinguish the data flows from each 
other and decompress them. To illustrate this, Figure 5b shows the 
compressor entity as two separate boxes, but in practice, there are two 
compression contexts within the same compression entity. The compressed 
data flows are, however, transmitted over the same RLC connection. 

[0041] Each PDCP entity can use one or more header field 
compression algorithms or not use any. Several PDCP entities can also use 
the same algorithm. The radio resource controller RRC negotiates a suitable 
algorithm for each PDCP entity as well as parameters controlling the algorithm 
and then advises the selected algorithm and parameters to the PDCP layer 
through a PDCP-C-SAP point (PDCP Control Service Access Point). The used 
compression method depends on the network-level protocol type used on the 
connection, the type being indicated to the radio resource controller when the 
PDP context is activated. 

[0042] In the UMTS system, header field compression of data 
packets being transmitted and decompression of received data packets are 
thus done on the convergence protocol layer PDCP. The tasks of the PDCP 
layer include functions related to improving channel efficiency, which are 
typically based on different optimization methods, such as utilisation of 
compression algorithms of data packet header fields. Since today the network- 
level protocols planned for UMTS are IP protocols, the compression 
algorithms used are those standardized by IETF (Internet Engineering Task 
Force). Thus, the ROHC compression method is especially well-suited for the 
UMTS system. The PDCP layer of the terminal typically supports several 
header field compression methods so as to allow connection establishment 
with as many network-level protocol types as possible. 
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[0043] When applying ROHC to the convergence protocol layer of 
UMTS, both the transmitting PDCP and the receiving PDCP comprise a 
compressor-decompressor-pair for compressing the data packets being 
transmitted and decompressing the received data packets. The convergence 
protocol layer PDCP provides the compression method ROHC a mechanism 
for negotiating the length of the context identifier for each radio bearer. In 
practice, the mechanism is implemented in such a manner that the PDCP 
layer transmits the messages of the compressor and decompressor on to RRC 
and the actual negotiation is done by RRC signalling. To be able to utilise the 
radio resources as efficiently as possible, the length of the context identifier 
CID is preferably defined as zero for the radio bearer. 

[0044] If the length of the context identifier CID defined for the radio 
bearer is "smaii", i e zero bytes, and all possible 16 data connections are in 
use, and if the user of the terminal wants to establish one more simultaneous 
data flow for a radio bearer having such a definition, a problem situation 
occurs, since 17 simultaneous data flows cannot be distinguished from each 
other with a "small" context identifier. Because a new data flow cannot be 
identified by its own context identifier according to ROHC specifications, a 
context identifier of an existing data flow will be defined for it. In such a case, 
two data flows having the same context identifier are transmitted 
simultaneously, which results in an error situation in the decompressor, 
because the decompressor can no longer distinguish the data connections 
from each other. A corresponding problem also arises with any other defined 
CID length value, when the radio bearer uses the maximum number of data 
connections defined for the length of the context identifier CID, and the user of 
the terminal tries to open a new data flow. Transmitting several data flows 
over a radio interface without header field compression leads to an inoptimal 
utilisation of radio resources, which is a hindrance to an efficient use of the 
entire mobile system. 

[0045] The problems described above can, however, now be 
reduced with the procedure of the invention, in which the parameters of the 
radio bearer are defined in such a manner that at least the number of data 
packet connection header fields allowed by the length of the defined context 
identifier can be compressed despite the fact that the number of data packet 
connections allowed by said context identifier length is exceeded. This way, it 
is possible to ensure that for instance when the length of the radio bearer 
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context identifier is set at zero and the user of the terminal wants to establish 
a 17'" simultaneous data flow for the radio bearer, at least the original 16, 
preferably all 17, data flows can be transmitted using ROHC. Correspondingly, 
with any other defined CID length value, when the radio bearer uses the 
maximum number of data connections defined for the length of the context 
identifier CID, and the user of the terminal tries to open a new data flow, it is 
possible to ensure that at least a number corresponding to the original number 
of data connections, preferably all data flows, can be transmitted using ROHC. 

[0046] According to a first embodiment of the invention, the 
definition described above can be performed by means of ROHC so that the 
ROHC algorithm is defined in such a manner that at least one value, 
preferably the last one, of the length of the context identifier CID, i.e. CID 
space, negotiated for each radio bearer is always reserved for an 
uncompressed data flow. Thus, it is possible to ensure that the data 
connections already in use can be transmitted compressed and, at the same 
time, a new data connection can be established without compression. The 
ROHC algohthm can, for instance, be defined on the basis of the negotiation 
between the compressor and decompressor in such a manner that if the 
length of the context identifier field is set to zero, the first 15 data flows are 
compressed, and if the user of the terminal tries to form a new (16"") data flow, 
it and any simultaneous data flows formed after it are transmitted 
uncompressed to the receiver. A CID field is attached to the uncompressed 
data packets to inform the receiver that their header fields have not been 
compressed and they should, thus, be directed past the decompressor. It is 
also possible to reserve for uncompressed data flows several values of the 
CID space of the context identifier field negotiated for the radio bearer. 

[0047] According to a second embodiment of the invention, the 
convergence protocol layer PDCP monitors the number of data connections 
and if the number of allowed data connections is exceeded, the PDCP layer 
informs the radio resources control protocol RRC of this, which then performs 
radio bearer reconfiguration during which the radio bearer parameters, 
especially the length of the context identifier, are re-defined so that the header 
fields of each data flow can be compressed according to ROHC. For instance, 
if the length of the radio bearer context identifier is set to zero and the PDCP 
layer detects 17 or more simultaneous data flows, the radio bearer is re- 
configured, whereby the maximum value of the context identifier field is 



